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A  Framework  for  Developing  and  Managing  Reuable  Avionics  Software 


Raghava  G.  Gowda,  PIlD. 

Assistant  Professor 
Depaitxnent  of  Computer  Science 
Univetsity  of  Dayton 

Abstract 

Developing  reusable  software  for  avionics  systems  is  a  challenge  to  software  engineers.  The  task  involves 
foreseeing  the  future  applications,  modeling  real-world  events,  using  appropriate  CASE  tools  throughout  the 
development  life  cycle,  and  providing  for  storage  and  retrieval  of  leosable  software  components.  This  report 
presents  a  model  for  developing  and  managing  reusable  software  components,  briefly  describes  the  software 
process  maturity  model  and  the  integration  of  CASE  tools  with  the  process  maturity  model  It  also  identifies  tools/ 
techniques  and  methodologies  for  real-time  systems  development,  examines  the  critical  issues  in  managing 
software  projects,  and  offers  the  management  a  set  of  guidelines  to  introduce  software  engineering  methndoingjf^ 
and  CASE  tools  within  the  organization  through  a  model  projea  which  may  enforce  standards  for  new  projects. 
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A  Framework  for  Developing  and  Managing  Reniabie  Avionics  Software 
Raghava  G.  Gowda,  Ph.D. 

IKTRQDUCTIQN 

It  has  been  a  great  opportunity  for  me  to  work  at  the  Wright  Laboratory's  Avionics  Logistics  Branch. 
During  my  stay,  I  had  opportunities  to  do  detailed  literature  survey  on  software  reusability,  go  through  some 
documentation  on  some  of  the  projects,  talk  to  consultants  assessing  software  process  maturity  of  the  branch, 
interaa  with  the  software  CASE  tool  vendors,  talk  to  various  project  managers,  arui  act  as  a  consultant  for  one  of 
the  projects  under  development  using  object-orieiued  approach. 

The  initial  objective  of  the  sununer  research  program  was  to  study  reusability  issues  in  avionics  software. 
The  approach  taken  was  to  do : 

A.  A  detailed  libraty  search  in  reusability  and  identify  design  criteria  for  reusable  software 

B.  Gather  design  details  about  reuse  efforts  such  as  Reusable  Ada  Avionics  Software  Packages  (RAASP) 
and  Common  Ada  Missile  Package  (CAMP) 

C.  StimmariTg  findingc 

As  it  was  not  possible  to  get  complete  information  on  these  projects,  the  research  effort  was  directed  to 
develop  a  ftamework  for  developing  and  controlling  reusable  software  in  the  avionics  domairL  Based  on  my 
research,  and  participation  in  weekly  review  meetings  of  a  simulation  project,  and  my  observations  during  my  stay 
here,  I  would  like  to  present  a  model  for  developing  and  managing  any  real-time  software  systems  such  as  avionics 
systems.  The  model  would  be  applicable  for  laboratories  which  initiate,  fund,  and  control  projects  as  well  as  to 
contractors  who  develop  the  systems. 

Because  the  subject  is  broad,  only  a  few  aspects  of  it  have  been  emphasized  in  this  report  It  is  not 
possible  to  offer  detailed  discussions  due  to  page  constraints.  After  defining  the  reusability  of  software,  a  life  cycle 
model  is  proposed  which  recognizes  maintenance  and  further  development  as  a  part  of  the  development  process. 
This  may  be  treated  as  a  life  cycle  model  of  reusable  software  (or  close  to  it).  Then,  the  role  of  software  maturity 
model  and  CASE  tools  in  software  developmetu  is  discussed  and  suggestions  are  offered  for  integration  of  CASE 
tools  acquisition  and  maturity  model  A  number  of  critical  issues  in  managing  software  development  tasks  are 
outlined.  Finally,  suggestions  are  offered  to  develop  a  model  project  within  an  organization  using  appropriate 
methodologies  and  (^ASE  tools.  This  will  help  an  organization  to  attain  higher  levels  in  software  process  maturity 
model  and  offer  insights  for  managing  and  integrating  various  projects.  This  experience  may  form  a  fourulation 
for  future  reusable  aviottics  software  developmem  tasks.  The  report  consists  of  the  following  major  topics: 
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1.  Software  Reusability 

2.  A  Life  Cycle  Model  for  Reusable  Software 

3.  Software  Process  Maturity  Model  for  ln>house  management  and  external  control. 

4.  CASE  Tools 

5.  Software  Process  Maturity  Model  and  Role  of  CASE  Tools 

6.  Critical  Issues  in  Managing  Software  Projects: 

6.1  Contents  of  Proposals  and  Deliverables 

6.2  Domain  Analysis  for  Avionics  and  Assessment  of  Available  Technology 

6.3  An  Integrated  View  of  all  Projects 

7.  A  Model  For  Developing  and  Managing  Reusable  Avionics  Software 

7.1  A  Model  Project 

7.2  Software  Development  Processes,  Methodologies,  and  Metrics 

7.3  Usi^  CASE  Tools  in  Projects 

7.4  Action  Plan 

L  SOFTWARE  REUSASn.rrv 

The  reusability  ofsoftware  is  the  ultimate  goal  ofany  software  development  effort  The  emphasis  has 
shifted  ftom  project>specific  systems  analysis  to  domain  analysis  in  order  to  incorporate  flexibility  in  analysis  and 
design  so  that  the  project-specific  efforts  can  be  reused  in  a  broader  domaiit  Developing  reusable  software  for 
avionics  systems  is  a  challenge  for  software  engineers.  The  task  involves  foreseeing  fixture  applications,  mtvfeitng 
real-world  events  using  appropriate  tools,  techniques,  and  methodologies  for  analysis  and  design  of  the  system,  and 
translating  the  specifications  to  software,  verifying  correctness  of  thesoftwareby  testing,  and  providing  for  storage 
and  retrieval  of  reusable  software  components.  The  software  engineering  discipline  offers  a  number  of 
methodologies,  tools  and  techniques,  and  metrics  to  assist  various  phases  of  software  development  activities.  The 
CASE  (Computer  Aided  Software  Engineering )  technology  integrates  most  of  the  tools  and  technirpies 

Reusability  has  been  defined  differently  by  various  authors.  Kemighan  [KER84]  defines  it  as  *...any  way 
in  which  previously  written  software  can  be  used  for  a  new  purpose  or  to  avoid  writing  more  software."  Bott  et  aL 
[BOT86]  give  a  mote  pragmatic  definition  of  reusability:  "  a  measure  of  the  ease  with  which  a  component  may  be 
used  in  a  variety  of  application  contexts."  In  general,  reusability  of  software  can  be  interpreted  from  multiple  view 
points.  First,  it  can  be  seen  as  the  use  of  existing  software  within  a  changing  environment  [SCHST].  Second,  it 
can  be  viewed  as  the  construction  of  new  programs  by  composing  such  a  program  from  software  components 
[LY086].  Third,  it  can  be  interpreted  as  the  construction  of  programs  by  program  transformation  [(ZHE84]. 

Reuse  can  generally  be  classified  as  the  reuse  of  ideas,  vertical  reuse,  hnriznntai  reuse,  and  total  reuse 
[HALS7].  Publishing  methods  and  techniques  including  algorithms  leads  to  reuse  of  ideas  by  software 
professionals.  Vertical  reuse  refers  to  reuse  in  a  particular  language,  and  horizontal  reuse  refers  to  the  widely  used 
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components  in  a  paiticuiar  envuomnent.  such  as,  son  utilities.  Total  reuse,  however,  is  the  use  of  complete 
packages  after  some  customization. 


The  term  reuse  applies  to  the  products  developed  throughout  the  development  life  cycle  of  software  which 
includes  requirements  specifications,  logical  and  physical  design,  code,  and  any  information  needed  to  create 
software.  A  Reuse  Taxonomy  by  Prieto-Diaz  (PRI931  shows  six  views  of  software  reuse: 

1.  Bv-Substance  defines  the  essence  of  the  items  to  be  reused.  It  consists  of  ideas, 
concepts,  artifacts,  components,  procedures,  and  skills. 

2.  Bv-scope  defines  the  form  and  extent  of  reuse.  Such  reuse  can  be  classified  as  vertical  and 
horizontal  reuse. 

3.  Bv-mode  defines  how  reuse  is  onnAicted-  It  may  be  planned,  systematic  or  ad-hoc, 
opportunistic. 

4.  Bv-technioue  defines  the  approach  used  to  implemem  reuse.  It  could  be  either 
conqxisitionai  or  generative. 

5.  Bv-intenrion  defines  how  elements  will  be  reused,  as  black-box  (as  is)  or  white-box 
(modified). 

6.  By-product  defines  what  work  products  are  reused.  It  includes  source  code,  design, 
specifications,  objects,  text  aiul  architecture. 

The  broader  concqjt  of  reuse  ( Basil!,  1988)  includes  the 'use  ofeveiything  associated  with  a  software 
project  including  knowledge.*  TL;  emphasis  in  industry  has  been  on  artifacts  reuse  such  as  Booch  Ada  Parts 
collection  and  the  Generic  Reusable  Ada  components  for  Engineers.  Two  of  the  often  cited  reusable  projects  in 
Avionics  are  Common  Ada  Missile  Package  project  (CAMP)  and  Reusable  Ada  Avionics  Software  Packages 
(RAASP).  The  increased  focus  on  software  reusability  is  attributed  to  an  overall  realization  of  the  potential 
benefits  of  not  only  reusing  code,  but  also  using  all  aspects  of  the  development  process.  The  documentation 
produced  at  various  levels  should  serve  as  sources  for  Tnaintenance  and  reusability.  Reusability  of  software  can  not 
be  a  uniform  process;  it  always  has  to  be  tailored  for  a  particular  domain. 

1  ROLE  OF  USERS  AND  DEVELOPERS  IN  DEVELOPING  REUSABLE  SOFTWARE 

Users  of  software  can  be  classified  as  immediate  users  of  the  software  for  whom  software  was  developed  in 
the  first  place,  and  future  users  of  the  software.  Tmmi»diatK  users  are  more  concerned  about  the  ability  of  the 
software  in  meetinr;  requirements  for  the  application,  budget,  and  time  factors.  Their  objectives,  however,  may 
not  be  the  same  as  those  of  future  users  who  tend  to  generalize  software  attributes,  which  in  turn  could  lead  to 
additional  costs  and  delays  in  development  efforts  and  enhancements.  Immediate  users  may  not  favor  domain 
analysis  unless  they  realize  the  need  for  future  developments  and  also  its  cost  implications.  Future  users  could  play 

5-5 


a  role  siiniiar  to  thri  of  assembly  line  worken  who  assemble  software  aumioiientt  to  ptodme  a  nav  Tbe 

reuse  of  thi'  same  software,  however,  will  vary  depmriing  on  the  ability  of  the  user  and  the  features  of  the  software 
components. 


The  abilities  of  the  users  of  software  components  are  a  combination  of  skill  levels  of  the  users,  ^miliarity 
of  the  problem  domain,  and  the  time  taken  to  regieve  required  componenti  from  reuse  rqtositoiy.  The  tasks  of  the 
users  will  also  be  fadlitatrd  by  the  characteristics  of  the  componenti  themselves.  These  component  characteristics 
are  incorporated  in  the  software  by  the  software  engineer  and  the  developinent  team. 

It  should  be  emphasized  that  the  major  players  in  softwaic  reusability  are  users  and  developeis .  A 
Reusable  Components  Repository  is  the  common  base  through  which  they  interact  Users  are  concerned  with  the 
case  of  using  the  repository  and  developers  are  concerned  with  popolating  the  lepositoiy  and  keeping  track  of 
engineeiing  details. 


f 

Reuse 

Repositaiy 

User 

V _ > 


Figure  1.  Reusability  Scenario 
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The  reusability  scenario  has  two  distinct  features;  a  Repository  Retrieval  System  and  the  Components 
Engineering  System  which  consists  of  domain  analysis,  requirements  analysis,  design,  metrics,  and  other 
configuration  management  details.  Both  the  Repository  Retrieval  System  and  Components  Engineering  System 
have  to  be  designed  in  collaboration  with  each  other.  A  Repository  Retrieval  System  is  similar  to  a  library  rrmeval 
system,  but  it  has  to  consider  graphical  interfaces  and  capabilities  to  interface  with  other  software  repositories 
planned  by  DoD  and  commercial  software  vendors.  Even  though  reusable  efforts  are  evolving,  standards  for 
interface  with  repositories  are  not  easily  available.  Therefore,  retrieval  systems  need  flexible  designs. 

Extracting  reusable  components  fix)m  existing  software  is  a  complex  activity  and  may  not  be  cost 
effective  in  all  cases.  The  basic  information  needed  for  reusable  components  firom  the  users'  perspective  are: 

a.  Domain  knowledge 

b.  Overview  of  reusable  components 

c.  Details  of  each  component  which  include: 

Source  code  adhering  to  a  particular  style 
Domain  analysis 

Requirements  analysis  of  the  system  for  which  the  component  was  designed 
Logical  Design 

System  (hardware/software)  constraints 
Testing  /  Quality  Assurance  reports 
Unique  features  etc. 

Other  aspects . 

2.  A  LIFE  CYCLE  MODEL  FOR.  REUSABLE  SOFTWARE 

Software  Development  Life  Cycles  offer  a  framework  for  software  development  Though  there  is  some 
concern  about  the  life  cycle  concept  itself  amid  its  use,  one  Has  to  admit  thwr  utility  in  identifying  various  mdf* 
involved  in  the  software  development  Software  professionals  are  well-versed  with  the  following  life  cycle  noodels: 

1.  Classical  Software  Development  Life  Cycle 

2.  Structured  Software  Development  Life  Cycle 

3.  Software  Engineering  Life  Cycle 

4.  Information  Engineering  Life  Cycle 

5.  Spiral  Model  of  software  development  and  enhancetnem 

The  life  cycle  models  presem  differem  points  of  view  for  systems  development  For  example,  the  classical 
model  assumes  that  the  various  activities  are  sequential.  This  model  has  been  widely  critiqued  for  its  inability  to 
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incorporate  changing  system  needs.  The  Structured  Life  Cycle  considers  back-tracking  and  incorporating  changes 
introduced  at  various  phases,  The  Software  Engineering  Life  Cycle  closely  follows  the  Classical  and  Structured 
life  cycles  and  emphasizes  walkthroughs,  inspections,  reuse,  metrics,  and  deliverables.  Information  Engineering 
C>'cye  emphasizes  defining  data  requirements  of  an  enterprise  first,  and  then  the  processes.  It  may  be  more 
appropriate  for  developing  Management  Information  SyAems  projects.  The  Spiral  Life  Cycle  H«alf  with  the 
prototype  development  etrvironment,  where  neither  the  developer,  nor  the  user  have  complete  knowledge  of  the 
product  to  be  developed.  It  considers  risk  analyses  for  different  prototype  develt^metus.  None  of  the  above  tn»v<eW 
treat  software  reuse  or  maintmann^  as  a  part  of  the  models.  Incorporating  mainffmanni-  and  reuse  paradig™  in  the 
model  forces  the  developer  to  consider  a  futuristic  view  of  the  system  during  development 

Henderson-Sellers  and  Edwards  [HEND90]  propose  the  Fonntain  Model  (Figure  2)  for  the 
object-oriented  life  cycle  which  consists  of  the  traditional  life  cycle  phases  and  three  addirinnai  phases  of  fivgram 
Use,  Maintenance,  and  Further  Development  at  the  top  of  the  Fountain  The  model  extends  the  Waterfall  or 
Structured  Life  Cycle  models  to  include  reuse,  tnaintewanee  and  further  enhancements  of  software.  The  Fouiuain 
Model  represents  object-orierued  software  life  cycle.  It  may  also  be  treated  as  reusable  software  development  life 
C3rcle,  where  Maintenance,  and  Further  Development  are  some  aspects  of  reuse  efforts.  We  would  like  to  add 
Domain  Analysis  prior  to  Requirements  Analysis  phase  in  the  Figure  2  to  emphasize  the  fan*  that  reusability 
issues  should  be  domain  specific,  because  designing  software  for  univeisal  reusability  may  not  be  cost-effective  and 
practical. 

Domain  analysis  plays  a  significant  role  in  the  development  of  reusable  software.  Domain  anat^’sis  refers 
to  a  detailed  survey  of  the  past  efforts  of  an  application  area,  current  developmeitt  tadra  and  future  needs  of  the 
problem  domaiiL  Domain  analysis  will  allow  the  managers  and  developers  to  integrate  past  and  current  efforts, 
schedule  for  the  optimum  utilization  of  resources,  and  substantial  savings  in  time  and  efforts  in  development, 
maintenance,  and  enhancements  of  systems. 
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The  basic  elements  of  a  management  process  are:  planning,  organizing,  operating  and  control.  For  an 
organization  such  as  Software  Concepts  Group  at  the  Avionics  Directorate  of  the  Wright*Patterson  Air  Force  Base, 
which  forecasts  technology  for  future  avionics  systems,  translates  the  concepts  to  feasible  projects,  funds  and 
monitors  the  projects,  and  diffit^es  the  technology  to  its  customers,  and  to  the  community  at  large,  rnanagemem 
issues  become  very  complex.  We  can  view  management  functions  from  two  perspectives: 

1.  Internal  control 

2.  Controlling  projects  developed  by  contractors. 

The  task  of  foreseeing  the  future  technology  is  the  most  ciudal  one.  As  the  projects  are  of  diverse  nature, 
it  may  not  be  possible  to  use  the  same  set  of  tools/techniques  or  CASE  tools  in  ail  the  projects.  However,  a  few 
guidelines  could  be  offered  to  maintain  uniformity  among  projects.  It  is  necessary  to: 

a.  Provide  a  conunon  format  for  all  projects; 

b.  Maintain  control  over  all  documentation  and  souroe  codes; 

c.  Record  contributions  of  individual  projects  with  respect  to  contribution  to  knowledge,  technology, 
products,  etc. ; 

d.  Encourage  use  of  software  engineering  principles  and  CASE  tools  wherever 
appropriate; 

e.  Integrate  contributions  of  all  the  projects  and  ptacdoe  them  in  the  subsequem  projects. 

The  Software  Process  Maturity  Model  (HUM89)  would  be  equally  applicable  to  Laboratories  controlling 
projects  as  well  as  to  contractors  involved  in  software  developmeitt.  If  the  Laboratories  have  a  high  level  of  process 
maturity  then  they  will  be  in  a  position  to  demand  and  control  appropriate  deliverables  from  their  contractors  more 
effectively.  The  software  process  is  the  entire  set  of  tools,  methods,  and  practices  used  to  produce  a  software 
product 


Figure  3.  Software  Process  Maturity  Levels 
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Control  and  improvement  of  tools,  methods,  and  practices  can  lead  the  organization  to  higher  maturity 
levels.  Metrics  or  measuremem  of  outputs  can  play  a  major  role  in  translating  the  art  of  software  development  to 
the  science  of  software  development  CASE  tools  will  also  play  a  major  role  in  the  software  process  maturity 
model. 

4,  CASE  TOOLS 

This  section  outlines  the  specifics  of  the  avionics  software  development  process.  The  riwnand^  of  avionics 
software  development  process  are  quite  distinct  ftom  those  of  Management  Infonnatioa  Systems  or  any  other 
commercial  triplications.  Most  of  the  avionics  applications  are  embedded  real-time  systems.  The  new  applications 
ate  to  be  developed  using  Ada.  Some  of  the  tools/techniques  and  methodologies  required  to  specify  the 
requirements  and  design  of  the  avionics  systems  are  as  follows: 

A  Structured  Analysis  and  Design  Methodology 
Tools/Techniques  Used: 

1.  Data  Flow  Diagrams  and  its  Real-Time  extensions 

2.  Data  Dictionary 

3.  Data  Modeling  and  Entity  Relationship  diagrams 

4.  Decision  Tables,  Decision  Trees,  Action-Diagrams,  Nassi-Shneiderman  charts 

5.  State  Ttansition  Tables,  State-Transition  Diagrams 

6.  Fiaite-State  Architecture 

7.  Petrinets 

8.  Structure  Charts  (in  Structured  Design  Methodology) 

B.  Data  Structure-Oriented  Methodologies 

1.  Wamier/OtT  Methodology 

2.  Jadcson  System  Development  (JSD) 

C.  Real-Time  Design  Methodologies 

1.  Design  Method  for  Real-Time  Systems  (DARTS) 

2.  Struchired  Analysis  and  Design  Technique  (SADT) 

D.  Object-Oriented  Analysis  and  Design  Methodologies: 

1.  Bailin:  Object-Oriented  Requirements  Specification 

2.  Coad  and  Yourdon:  Object-Oriented  Analysis  and  Object-Oriented  Design 

3.  Shlaer  and  Mellon  Object-Oriented  Analysis 

4.  Wassennan  et  aL  Object-Oriented  Structured  Design  (OOSD) 

5.  Boocb:  Object-Oriented  Design 

6.  Wirft-Brock  et  al.  Responsibility  Driven  Design  (RDD) 
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7.  Rumbaugh  et  al.  Object-Modeling  Technique  (OMT) 

8.  EmbleyetaL  Objea-Oriented  Systems  Analysis  (OSA) 

These  methodologies  can  be  implemented  in  most  of  the  leading  CASE  tools.  In  general,  the  CASE  tools 
can  be  classified  finom  multiple  view  points  such  as  upper  CASE,  lower  CASE,  and  I-CASE  (Integrated  CASE 
Tools).  Some  of  the  unique  components  of  the  CASE  Tool  set  are  (BUR  89]  summaiized  below; 

a.  Diagramming  Tools 

b.  Syntax  Verifiers 

c.  Prototyping  Tools 

d.  Code  Generators 

e.  Project  Management  and  Methodology  Support 

f.  Re-Engineering  Tools 

g.  Central  Repository 

At  present  about  24%  of  the  software  development  organizations  nse  CASE  tools.  Most  of  the  tools 
implemem  Structured  Systems  Analysis  and  Design  methodologies,  but  they  are  not  well  integrated  with  code 
generation  and  testing  tools.  One  of  the  major  problems  is  the  compatibility  among  CASE  tools.  Lackofindnstry 
standards  makes  it  difficult  to  port  systems  fix>m  one  set  oftools  to  another.  It  also  makes  users  dependent  on  a 
particular  tool  vendor.  Organizations  generally  are  hesitant  to  adopt  this  new  technology  because  of  high  cost 
investments  in  these  tools  as  well  as  the  costs  involved  in  training  employees  in  the  methodologies  and  tools. 
Moreover  the  management  of  an  organization  has  high  expectations  about  p^-off  fiom  these  tools  but  employees 
are  reluctam  to  experiment  with  the  new  technology.  The  opponents  of  CASE  tools  may  be  concerned  about  the 
following  issues: 

1.  Training  with  methodologies 

2.  Ease  of  use  of  CASE  Tools 

3.  Rerilinrianries  in  rinmniwit^rinn 

4.  Poor  integration  of  various  phases  of  lifecycle 

5.  High  costs  of  acgnisirion  and  maintenanee 

6.  Probability  and  compatibility  of  the  tools 

These  are  some  of  the  concerns.  Itshould  be  kept  in  mind  that  CASE  technology  is  still  evolving  andit 
might  take  a  while  to  have  an  1-CASE  in  its  real  sense.  If  an  organization  ready  to  cope  with  the  technology,  it  is 
the  time  to  start  now!  We  have  to  keep  in  mind  that  acquiring  knowledge  always  comes  incrementally.  Training 
employees  with  software  engineering  methodologies  is  clearly  the  most  crucial  aspect  A  careful  evaluation  of  the 
tools  that  will  be  needed  should  be  done  prior  to  their  acquisitioit  Consultations  with  users  of  some  of  the  tools  in 
similar  projects  seems  to  be  the  most  desired  method  for  evaluation  of  the  tools.  It  would  be  an  ideal  approach. 
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however,  to  train  project  managers  on  a  Model  Project  which  would  be  of  oonunon  interest  Various  software 
engineeting  tools/techniques  can  be  experimented  in  the  Model  Project  For  example,  an  expert  in  the 
methodology  may  act  as  a  moderator  in  the  development  process.  In  learning  the  development  process  education 
in  software  engineeriag  disciplines  would  be  more  benefidal  as  compared  to  training  with  a  specific  CASE  tool 
because  it  is  not  the  tool  which  decides  the  success  of  any  project  but  the  modeling  or  problem  solving  annoach 
which  dictates  bow  well  the  tool  is  used  to  develop  the  system. 

Most  CASE  tools  are  cqiable  of  producing  documents  adhering  to  2167A  standards.  However,  it  is  the 
responsibility  of  the  management  to  enforce  uniformity  in  the  contents  of  deliverables  by  giving  specific  directions 
regarding  formats,  tools/techniques,  methods,  and  cross>referencing  in  the  doaimentatioa  The  ultimate  objective 
is  always  to  get  an  integrated  product  which  is  easy  to  operate,  maintain,  and  reuse.  This  could  be  accomplished 
by  enforcing  standards  with  respea  to  the  tools,  techniques,  and  other  process  details. 

5.  ■SOFTWARE  PROCESS  MATURITY  MODEL  AND  ROLE  OF  CASE  TOOLS 

Pfleeger  (PFL91]  suggests  that  "only  when  development  process  possesses  sufficient  structure  and 
procedures  does  it  make  sense  to  incorporate  certain  land  ofCASE  tools  in  a  development  environmem."  He 
advocated  the  following  CASE  tools  for  the  various  process  maturity  levels. 


Level 

Chaxacteristics 

Mdrictouse 

CASE  Tools 

1. 

Initial 

Adhoc 

Baseline 

Tools  that  bdp  to  structure  and  controL 

estimate  produa  size  and  effort 

Repeatable 

Process  dependent 

on  individuals 

Project 

Tools  for  requirements  specification, 

project  management,  and  configuiatiom 

management 

3. 

Defined 

Process  defined, 

insritutionaiized 

Product 

Tools  to  measure  quality,  complexity,  to 
support  design  and  coding,  and  to  guide 

testing  and  integration 

Managed 

Measured  process 

(quantitative) 

Process Feedback 

Project  database,  management  system, 

simuJation  tools,  reliability  models,  and 

impact  analysis 

3. 

Optitnizing 

Itnrovement  fedback 

to  process 

Process -i- Feedback 

for  changing  process 

Process  programming  and  process 

simuiation  tools 

Figure  4.  Process  maturity  leveb  related  to  CASE  tools 
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6.  CRITICAL  ISSUES  IN  MANAGING  SOFTWARE  PROJECTS 

Issues  involved  in  software  project  management  are  numerous  and  quite  complex.  Some  of  the  key  issues 
which  have  tremendous  impact  on  delivetables,  usability,  and  control  of  the  projects  are  the  following: 

6.L  CONTENTS  OF  PROPOSALS  AND  DELIVERABLES 

After  going  through  a  number  of  proposals,  work  plans,  deliverables,  etc.  1  realized  the  in 

managing  the  projects.  Even  with  my  adequate  badcground  in  the  software  mginerring  area,  1  felt  that  I  would  be 
atthemercy  of  the  contractor  if  I  were  a  manager.  The  reason  is  that  I  may  not  have  enough  control  over  the 
projects.  The  DoD  has  all  the  controls  in  place  for  managing  the  projects  through  standards  such  as  2167A,  but 
the  documentation  I  read  rais«d  the  following  questions  which  could  serve  as  guidelines  for  an  organization: 

1.  What  are  the  contributions  ofthisprojea  in  terms  ofknowledgeaiul  technology? 

2.  Have  similar  projects  been  undertaken  fay  the  same  contractor,  by  other  agendes,  or  by  other 
organizations  in  U.S.  or  abroad? 

3.  How  well  the  contractor  oonqtleted  the  "Related  Work*  section  in  the  proposal? 

4.  Can  we  have  full  control  over  the  deliverables? 

5.  Does  the  contractor  make  us  depend  on  the  particular  contractor  for  related  efforts  in 
ftiture  by  the  nature  of  deliverables,  or  mode  of  information  sharing? 

6.  How  well  the  requirements  specification  is  separated  fiom  design  issues? 

7.  Has  the  oontirmity  among  various  phases  of  systems  development  been  demonstrated  by 
the  contractor? 

8.  How  well  the  project  is  integrated  with  other  picrjects  in  the  Avionics  Directorate? 

9.  How  easy  is  it  to  follow  documentation  and  other  deliverables? 

10.  Do  we  have  metrics  to  assess  deliverables? 

6.1.1  SOURCES  OF  CONHISTON 

I  strongly  believe  that  one  of  the  major  sources  of  confusion  can  be  in  the  proposal  itseift  in  which  the 
contractor  fails  to  distinguish  between  the  requirements  ofa  system  and  the  design  of  the  system.  Systems 
analysisor  requirements  analysis  should  emphasize  only  on  "what*  is  expected  of  the  system,  and  not  "how”  it  is  to 
bedone.  Unfbitunateiy  most  of  the  proposals  I  read  did  not  distinguish  between  analysis  and  design.  Thisladcof 
distinction  blots  the  basic  objectives  of  tbe  project.  Additionally,  it  is  difiScult  to  evaluate  the  aignoach  as  no 
alternatives  ate  given.  Tbe  proposal  may  be  too  detailed  about  a  qredfic  mode  of  implementation  so  that  the 
reader  is  lost  in  the  details  or  led  to  believe  that  it  is  the  only  way  to  do  things.  In  such  a  scenario  the  manager  has 
no  option  but  to  aoc^  the  tasks  as  outlined  in  the  proposaL  The  manager  will  not  have  much  control  over  the 
project  as  the  pngMsal  did  not  specify  microscopic  details.  Only  an  expeit  in  tbe  particular  area  may  raise 
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meaningful  questions.  The  other  alternative  which  I  may  be  forced  to  adopt  because  of  the  nature  of  proposal,  is  to 
keep  quiet  and  be  satisfied  with  whatever  deliverables  ate  received  firom  the  contractor.  To  overcome  these 
difficulties,  1  would  ask  the  contractor  to  stnctiy  follow  the  following  guidelines: 

1.  Specify  the  system  tequiiements  without  referring  to  any  hardware  or  produa  details. 

2.  Discuss  implementation  details  in  the  Design  aspects. 

3.  Do  not  mix  "What”  and  ”How*  aspects. 

4.  Describe  contents  of  deliverables.  Especially,  identify  what  type  of  methodologies,  CASE  tools  etc. 
would  be  used  for  analysis  and  design.  Describe  how  documentation  of  one  phase  will  lead  to  the 
successive  phases. 


Investment  in  research  projects  related  to  technology  development  is  potentially  a  high  return  area  if  it  is 
conceived  and  managed  very  carefully.  Otherwise  investments  may  not  produce  oihgtantiai  outputs.  Every  efic  t 
should  be  made  to  diffuse  the  technology  to  the  comiminity  at  large  and  break  the  monopoly  of  a  few  vendors.  In 
avionics  domain,  the  main  thrust  is  both  in  software  development  artd  technological  advancement  Inboththe 
cases,  outputs  of  the  projects  need  to  be  carefully  evaluated  and  controlled. 
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In  the  1960's  Original  Equipment  Manufiutnrers  (OEM)  controlled  the  hardware  industry  because  of  their 
unique  coding  schemes.  This  ^roach  made  the  user  dependent  on  a  particular  vendor  of  hardware.  Introduction 
of  ASC  n  solved  this  problem  to  some  extent  Now  a  simiiar  scenario  exists  today  in  the  software  iiufaistry. 
Though  there  ate  standards  such  as  2I67A  for  documentation  of  software,  the  contents  of  documentation  vary 
because  of  different  tools  and  techniques  used  in  software  development  and  the  lack  of  detailed  standards  and 
process  control 

In  the  absence  of  matured  processes  for  software  develcqtment  a  reasonable  control  on  the  project  can  be 
achieved  by  defining  the  contents  of  delivetables.  To  some  extent  the  contents  would  define  the  process  and 
enforce  uniformity  in  managing  projects.  One  of  the  aspects  which  need  to  be  emphairized,  however,  is  to  separate 
logical  requirements  fiom  implementation  details,  This  is  the  key  to  extend  the  life  of  the  systertL 


Domain  Analysis  is  the  formulation  of  the  ootrunon  elements  and  structure  of  a  domain  of  applications  Q. 
It  is  a  way  of  understanding  and  describing  the  past  and  present  in  order  to  increase  productivity  in  the  future.  It 
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should  be  an  ongoing  process.  Domain  Analysis  in  avionics  refen  to  surveying  the  avionics  applications  and 
assesses  the  role  of  the  current  and  past  projects  in  the  avionics  domain  applications.  One  of  the  objectives  of 
domain  analysis  is  to  develop  a  fiamewoik  for  integrating  all  tasks  in  avionics  domaiiL  Some  of  the  questions 
which  may  be  useful  in  this  contcoct  are: 

X  What  is  the  lautwledge  base  for  major  air  frames  for  example,  (current  and  future  fighters,  bombers, 
helicopters,  and  trainers)  regarding  their  current  functions,  missions,  environments  and  future  plans? 

b.  What  ate  the  goals  and  objectives  of  this  group  with  respect  to  software  and  hardware  under  its  control? 

c.  Do  we  know  the  of  all  current  projects,  and  deliverables  within  a  suitable  format? 

d.  Do  the  current  projects  meet  goals  and  objectives?  To  what  extent? 

e.  What  applications  are  better  for  reusability,  in  terms  of: 

i)  analysis 

ii)  design 

iii) oode 

iv)  algorithms 

f.  Are  projects  aimed  to  develop  prototypes  and  concepts  doaimenting  the  outputs  in  such  a 
manner  that  they  could  be  used/implemented  by  any  independent  team? 

g.  Which  projects  undertaken  by  DoD,  ARPA,  NSF,  other  agencies,  and  private  organizations  are  similar 
to  the  current  one?  Describe  them. 

h.  Is  a  format  for  domain  analysis  documents  developed? 
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Each  project  should  have  documentation  on  various  phases.  DoD  Standard  2167A  deals  with  the  details 
and  these  should  be  followed.  For  the  purposes  of  managing  projects,  the  Avionics  Directorate  may  develop  a 
document  giving  an  integrated  view  of  the  projects  under  its  controL  A  yearly  report  may  be  compiled  tdiich  will 
consist  of  the  following  essential  aspects  of  all  the  projects  and  how  they  are  integrated: 

1.  Domain  Analysis 

2.  Contributioos  of  the  Project 

3.  How  these  contributions  are  integrated  with  other  Avionics  projects  or  any  other  efforts? 

The  major  emphasis  of  this  yearly  report  should  be  on  concepts  on  technology  advances  and  on  aspects 
which  could  be  used  elsewhere.  Implementation  details  are  available  at  the  project  level  and  as  such  should  not  be 
part  of  this  report 
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7^MQDEL  FQRL>EVET.OPTNrT  AND  managing  REUSABLE  AVIQNICS  SQFTWARF 


Based  on  the  past  discussioiis,  a  Model  for  Developing  and  Managing  Reusable  Avionics  Software  is 
offered  in  Figure  5. 


AVIONICS  DOMAIN  ANALYSIS 


Past 

Cunent 

Future 

Projects 

Projects 

Projects 

Re-engineenng 

Real-Tune 

Revene  cacneeiiac 
CASETooIt 

Software  Oeveiopment  MetbodoUjgiea 
CASETooIt 

SOFTWARE  PROCESS  STANDARDS  J 


MODEL  PROJECT 
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Rente  Companeott 


AviooiGs 

Softwtxe 

Syitenu 


Object-Oriented 

Software  Development 
Methodologies 

Smictured  Systems 
Development 
Methodologies 
with 

Real-Time 

Extensions 

Ada 

Ada9X 

INTEGRATED  CASE  TOOLS 

V. 


DoD  STANDARD  2167A 
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Figure  5.  A  Model  For  Developing  and Manapng  Reusable  Avimica  Software 
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To  standardize  the  piojea  formats  and  to  appreciate  technical  details,  it  will  be  useful  to  work  on  a  Model 
Project  with  close  collaborations  with  a  developer  or  consultant.  It  may  be  useful  to  te^gineer  an  existing  projea 
which  will  have  high  reusability  because  the  existing  project  will  have  all  technical  details.  If  however,  a  new 
project  is  selected  the  emphasis  will  shift  to  new  tarhnifsii  details  and  exploration  aspects.  Therefore,  a  new 
project  may  be  restrictive  in  exploring  all  tools^techniques,  methodologies,  and  other  issues.  The  difBculty  in 
ie<ngineeting  an  existing  project  would  depend  on  the  availability  of  doQimetrts,  style  of  coding,  and  the  language 
used. 

The  Model  Project  should  be  developed  using  appropriate  methodologies,  CASE  tools,  and  documentation 
should  adhere  to  standard  2 167A.  It  should  serve  as  a  model  for  use  nf  melhndftlogiea  and  rinrumwifatinii  This 
experience  may  be  valuable  for  in*house  development  and  in  managing  software  development  projects  by 
contractors. 


Avionics  software  systems  have  a  number  of  characteristics  which  make  them  unique  compared  to  the 
traditional  data  processing  application.  In  general,  they  are  real«time  systems  udiich  need  to  activate  as  a  response 
to  external  events.  Re^nse  time  is  critical  for  such  systems.  Some  of  them  may  be  embedded  where  software  is 
integrated  with  hardware  components.  Correctness  of  software,  and  reliability  ate  of  utmost  concern  to  users  of 
the  software.  Therefore,  testing  of  software  is  a  very  elaborate  task  in  its  development  The  system  needs  to  be 
maintainable  at  the  earliest  possible  time.  On-board  testing  and  maintMianc^  efforts  would  minimiTg  the 
machine-down-time.  Most  of  the  tools  and  techniques  identified  earlier  would  also  be  applicable  to  avionics 
software  development 

Object-oriented  methodologies  are  very  well-suited  for  developing  reusable  software.  The  concepts  of 
abstraction,  infoimatioa-hiding  and  potymoiphism  are  practiced  in  these  methodologies.  Though  there  are  a 
number  of  OOA,  OOD,  OOA  and  OOD  methodologies,  they  are  not  in  a  matnred  stage  such  as  Structured 
Methodologies.  The  Object  ^fodeiing  Technique  by  Rumbaugh  et  aL  [RUM91]  seems  to  be  one  of  the  most 
appropriate  methodologies  for  avionics  system  development  as  it  offers  Olqect  Model,  Dynamic  Model,  and 
Functional  Model  facilities  for  requirements  specification  of  a  system.  It  is  a  nice  blend  of  structured  and 
object-oriented  concepts.  The  methodology  may  need  further  refinements  to  provide  contimiity  among  the  three 
models  and  to  represent  collaboration  between  various  subsystems  and  objects.  A  CASE  Tool  called  OMTool™ 
implements  the  methodology.  However,  it  is  to  be  kept  in  mind  that  at  present  OMTool™  does  not  iirqrlement  the 
Dynamic  Model  and  Function  Models  of  Rumbaugh's  methodology.  Representation  of  collaborations  between 


objects  and  integiatioa  of  diffetent  models  are  the  aajor  issues  regarding  this  methodology.  The  Model  Project 
may  use  Object-Oriented  and  Structured  methodologies  in  analysis  and  design  phases  and  Ada  in  impigmgntatinn 
phase.  Ada  9X  incorporates  objea-ohented  programming  features. 

7.3  USING  CASE  TOOLS  TNPROTFrrs 

At  present  most  of  the  CASE  tools  used  are  in  analysis  and  design  areas.  The  analysis  and  design 
methodologies  are  not  well  integrated  CASE  tools  related  to  project  management,  code  generation,  and  testing 
should  also  be  used  wherever  applicable.  This  would  integrate  all  the  phases  of  life  cycle.  A  recent  report  finom 
Institute  for  Defense  Analysis  has  identified  that  there  are  more  600  testing  tools  available  but  not  widely 
used.  The  CASE  technology  is  heading  towards  I-CASE  or  Integrated  CASE.  Managemgnt  may 
tools  progressively  in  projects.  As  discusted  earlier,  acquiring  different  tools  may  be  linked  to  different  levels  of 
process  maturity. 

7.4  ACTION  PLAN 

The  action*plan  may  emplutsize  standardising  processes  for  a  projecL  A  participative  mode  of 
implementing  a  change  in  an  organization  may  face  less  resistance  The  manager  may  do  the  following  for 
instance: 

1.  State  the  need  for  a  Domain  Analysis  for  Avionics  to  identify  the  future  technological  needs. 

2.  Show  how  the  existing  projects  meet  the  needs.  Emphasis  should  be  on  specifics.  Global  words 
should  be  avoided. 

3.  identify  goals  for  the  next  five  years. 

4.  Draw  an  implementation  plan  which  covers: 

a.  A  suggested  format  for  summary  arid  detailed  internal  reports  for  projects 

b.  Details  of  deliverahles  fiom  contractors 

c.  Software  Engineering  tools/techniques  to  be  used 

d.  Identify  the  need  for  a  Model  Project 

e.  Invite  suggesdoM  from  Project  Engineers 

g.  Incorporate  suggestions  and  implement  the  plaiL 

One  of  the  difficult  tasks  would  be  to  bring  projects  with  multiple  dimensions  under  a  common  thread  of 
control.  This  has  to  be  done  by  studying  individual  projects  and  then  comparing  their  similarities  and  differences. 
The  model  project  may  promote  uniformity  in  the  processes  i.e.  in  tools,  methods  and  practices  which  would  lead 
the  organization  to  a  higher  level  of  process  maturity  and  force  the  contractors  to  adhere  to  higher  standards. 
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